\chapter{geomagick}



\section{Design}

\subsection{Extensibility}
% wo plugin -> portability 
From the beginning of the project, it has been focused on keeping the library as
extensible as possible. Of course can this goal be reached in many ways. Since the
source code of the library will be provided to any one, one might ask, why there
should be a need to take care for extensibility at all. 
Indeed, any extendibility is possible, once the source code is available. But this
would mean, that anyone wanting to use the library would have to rebuild the library
from sources. And as a consequence, the library could no longer be used as a shared
library. 
It would therfore be fine, if no changes at the library would be required. This would
be given, would a plugin architecture like it is known from nullsoft's \emph{winamp} \footnote{http://www.winamp.com} or various
web browsers. This would however be quite a bit tricky to implement, further would
it be platform-dependent.
A much easier way to inject custom code into a precompiled library, is achieved by 
just passing a function-pointer to that library. By passing a function pointer actually
beeing a Constructor of a class, it is even possible to extend the library with previously
new classes (Types).
This lead to a separation of the library into a core consisting
essentially of a class named \emph{Conversion Manager} on one hand and a set of classes which
provide the actual geometric Types plus the Conversions on the other hand.
Those important classes are discussed below.

\subsection{Conversion Manager}
The \emph{Conversion Manager} which is the actual core of the library, keeps track
of all available geometric Types and Conversion and maintains a conversion graph. This means that
the \emph{Conversion Manager} will automatically update the graph it internally maintains, 
whenever the user registers or unregisters a geometric Type (BaseType) or a  Conversion.
Finally it finds conversion chains using a shortest path finding algorithm.


\subsection{Conversions}
Conversions are classes derived from the base class Conversion. A conversion is
identified through a std::string. This decision has been made in order to simplify
the maintaining of the Conversions. Maintaining Identifiers of the type integer can
become quite hard and often causes errors. This becomes even more crucial when
user provided Conversions are created and engaged. Further, conversions advertise
the source type from which they convert as well as the target type to which they offer
a conversion.
The most central attribute of any class derived from the class Conversion is certainly
the process method. This method implements the actual conversion and accepts thus the
source type and returns an Object of the target type of the Conversion.
In order to allow the Conversion Manager to build a conversion graph, the Conversions also
inform the Conversion Manager about their edge weight.
 
%Edge Weight
%process method


\subsection{BaseTypes}
% Inheritance diagram
There exists a set of classes derived from the class BaseTypes. Those classes
implement the actual geometric Types supported by geomagick. Figure \ref{fig:inheritance_diagram}
gives an overview of the currenly available types. It is important to notice, that
even tough the inheritance diagram shows the degree of relationship of two Types,
it doesnt show how they are best converted from one to another. It might be assumed,
that a good way to find a conversion from a given source type to a given target type
one should just convert the source type repeatedly to his parent type until a type
is reached which is also a parent type of the target node and from there, finally descending
the inheritnace tree in order to reach the target type. But this is not wise nor
is it always possible. There is neither a warranty claiming that those conversions exist at all,
nor that this conversion path would loose little information.

\begin{figure}[!ht]
    \begin{center}
        \includegraphics[scale=0.5]{figures/class_diagram_types0.png}
        \caption{!TODO inheritance diagram}
        \label{fig:inheritance_diagram}
    \end{center}
\end{figure}

Whereas the hierarchy given by the inheritance tree doesn't help directly finding
conversion path, it still brings some advantages. Most importantly, it prevents from
unnecessary code rewriting. Further, the strict hierarchy brings in some regularity,
which makes the use of the BaseTypes and the writing of Conversions easier. For example,
 the accessor method to access vertices has the same name
in the type Triangles as in the Type Polygons, since those Types
are both derived from the type MeshType.
% Another aspect to keep in mind...

